An earlier version of the design had separate drop built-in functions for the readable and writable ends of streams and futures, e.g. {stream|future}.drop-{reader|writer}, and the ABI included a t:<typeidx> for each of those, allowing tools and host implementations to know statically what specific type to expect, just like we've done for {stream|future}.{read|write|new}.

For symmetry with the rest of the built-ins, could we split waitable.drop back into subtask.drop and {stream|future}.drop-{reader|writer}? That would also make it clearer that {stream|future|.drop-writer can take an optional error parameter, but {stream|future}.drop-reader cannot.

@dicej Great point, and agreed. Split back up in this commit.

For visibility: this commit adds error and its associated canon built-ins, closing the TODOs in the original PR.

Thanks for all the excellent feedback everyone! I think the comments are dying down and it sounds like this is on a convergence path with @dicej's impl, so if nothing new pops up, I think I'll merge mid next week (and then we can continue to iterate on async in new issues and PRs).

FWIW, I think the next change I'd like to make is a PR that removes the DONE state from subtasks, which should simplify things and allow bindings for async borrows to make sense, and, after that, go through the top bullets of Async.md#TODO.

One other update: for both the pragmatic short-term benefit of avoiding parsing conflicts with the error resource type (defined by wasi:io/error) and, more generally, to help make it clear that it's just meant to convey non-deterministic, debugging-oriented contextual data, this commit renames error to error-context. This also nicely distinguishes error-context from the error case of the result variant (which contains the "whole" error value, including the WIT-defined error payload value).